The idea is to rather remove Holder and adding a private final SecureRandom numberGenerator = new SecureRandom(); to UuidVersion7Strategy, which will require that State#getNextState accepts a SecureRandom parameter.

LGTM assuming you managed to get tests to pass on Quarkus (as we discussed), thanks!

The idea is to rather remove Holder and adding a private final SecureRandom numberGenerator = new SecureRandom(); to UuidVersion7Strategy

Unfortunately if we do that, the UuidVersion7Strategy#INSTANCE, along with its SecureRandom, will end up in the heap just before native compilation, which will lead to the exact same problem.

Your suggestion could potentially work if the numberGenerator in UuidVersion7Strategy was lazily-initialized -- but even then I'm not entirely sure.

The removal of the numberGenerator access is indeed not enough, it's just the first part of a two-fold solution:

1. First commit: making sure that no access is made to numbergenerator before we actually generate UUIDs (i.e., at runtime for native applications).
2. Second commit: making sure that any native application using Hibernate ORM will initialize the Holder classes at runtime, ensuring the SecureRandom (and its seed) will be initialized at runtime.

This is enough to fix the issue in theory, and Jan checked this by running integration tests in my ORM 7 upgrade PR, so we should be fine.